An enterprise application software framework, such as Java® 2 Enterprise Edition (J2EE) platform, provides a rich set of resources, which include but are not limited to, component types, protocols, and system services that can be used to assemble an application or a service. As the scope of the J2EE architectural design space grows, the complexity of assembling solutions has also grown. It is important to properly manage the resources such that they can be used efficiently and correctly, since the cost of a subtle mistake can cause poor system performance or even system failure. The complexity and diversity of client access models to J2EE resources, however, stands in direct opposition to achieving this goal. Many of the resources in J2EE provide their own set of mechanisms for how they can be accessed, how usage can be parameterized, and how resources associated with them (connections, sessions, etc) can be managed. Depending upon the system architecture and components constructed by the system developer, the application developer, who may not be very experienced with object-oriented design and Java®/J2EE, might have to learn a variety of new technologies and interfaces(APIs) to work within the architecture. Since each individual J2EE technology presents a unique set of client APIs, configuration models, and resource management strategies, and each of which is unique, the learning curve is high and the potential for tooling and automation is relatively low.
Beyond adding to overall complexity, the diversity of J2EE resource types and access mechanisms also makes it difficult for tools to offer assistance to developers who need to use them. Specific resource types often need custom code in order to define wizards or property-driven user interface that aids a client of the resource. There has been few common mechanism for discovering the potential set of configurable attributes for a resource type, meaning that any graphical presentation of client attributes or wizards must be custom-authored based upon the underlying resource type.
Although significant progress has been made towards simplifying the deploying of enterprise application components (resources), the client access model to these components remains fragmented. Even where simplification is being pursued, it is being done in a manner that is often resource-specific. Although such resource-specific approach offers the potential for easier use of a particular resource type, a lack of unification or commonality in the access mechanisms makes it difficult for tools to support the development process and still presents a learning curve for users.